-**** Example: Runtime Generated Classes and Methods
-
-*** Intercessory
-
-Intercessory MOPs allow the user to customize language behavior by
-implementing methods which override certain aspects of the language
-behavior. This class of MOPs are what make MOPs especially
-powerful. No longer must a problem be restructured to fit the
-implementation language; the underyling language can be reshaped to
-fit the task at hand, and obfuscation of the intended structure of the
-application can be avoided.
-
-**** Example: Lazily Allocated Slots
-
-**** Example: Observer Design Pattern
-
-** Violation of Encapsulation?
-
-A MOP may seem like a violation of encapsulation by revealing some
-implementation details, but in reality a well designed protocol does
-not reveal anything which was not already exposed. Implementation
-decisions affect users, and some of these details do leak through to
-higher levels (e.g. the memory layout of slots). Implicit in the
-protocol specification are these implementation details, and the MOP
-merely makes this limited subset available for customization.
-
-A MOP makes it possible to customize certain implementation decisions
-that do not **radically** alter the behavior of the base language. The
-conceptual vocabulary of the system retains its meaning, and so code
-written in one dialect can interact with code written in another
-without knowing that they speak different ones.
-
-* MOP Design Principles
-
-** Layered Protocol
-
-A layered protocol design is good for both meta and normal object
-protocols, and enables a combinatorial explosion of customizations to
-the protocol.
-
-*** Top level **must** call lower level functions
-
-The top level methods of a layered metaobject protocol are required to
-call certain methods to perform some tasks. This both makes it easier
-to customize the top level methods (which perform very broad tasks) by
-providing some pieces of them for the programmer, and allows more
-customization to be done by opening up the replacement of lower level
-functions as a way to alter a small detail of the high level behavior.
-
-*** Lower level methods are easier to customize
-
-The lower level methods of a MOP are limited in scope and can be
-implemented easily. Often the changes to language behavior that are
-wanted are very small, and having methods that perform simple tasks
-which are often customized reduces the effort required to extend the
-system.
-
-** Functional Where Possible
-
-Functional protocols are preferred for MOPs (and object protocol in
-general). Functional protocols open up several optimizations for the
-implementation without burdening the user of the protocol.
-
-*** Memoization
-
-Memoization is the process of saving the results of a function call
-for future use. This avoids expensive recomputation of values which
-have not changed (recall that a true function will always return the
-same result when given the same arguments).
-
-A functional MOP can be optimized easily by exploiting this property
-to memoize the return values of calls to expensive operations. A MOP
-must be be very fast to avoid making programs unusably slow, and
-memoization is able to give an appreciable speedup in many cases
-without an insignificant burden on memory usage.
-
-**** Constant Shared Return Values
-
-Disallowing the modification of values returned by protocol methods
-allows the implementation to return large data structures by reference
-to avoid expensive copying without having to do expensive data
-integrity checks.
-
-*** Cleaner Code
-
-** Procedural Only Where Neccesary
-
-Some operations like method invocation are inheretly stateful and so
-must use a procedural protocol. There is no benefit to be gained from
-using a functional protocol, and indeed an attempt would result in
-obtuse code that severely restricted the implementor. Do note that
-only a very small part of method invocation is stateful (the actual
-call), and most of it can be implemented functionally (e.g. computing
-the discriminating function).
-
-* Examples
-
-** Object Inspector
-
-A primitive portable object inspector is presented here.
-